Eager load all API specs and reduce memory usage#285
Open
Conversation
Member
|
Silly question, but why are specs being loaded in production at all? |
Author
|
Not sure! I'd love if they weren't. It seems like they're needed for validation and to differentiate which parameters go in the path and which are query strings. (also looks like I missed some test issues, will fix tomorrow) |
ndonewar
reviewed
Dec 1, 2023
jhawthorn
force-pushed
the
fix_eager_loading
branch
from
bf88277 to
664d22b
Compare
Baseline:
$ ruby -I lib -e 'puts `ps -o rss= -q #{$$}`'
16256
Before:
ruby -I lib -e 'require "elastomer_client/client"; puts `ps -o rss= -q #{$$}`'
20724
After:
ruby -I lib -e 'require "elastomer_client/client"; puts `ps -o rss= -q #{$$}`'
27332
Previously this didn't truncate the file, so if the newly generated file was smaller it would create a syntax error. This also avoids loading anything except for version_support, since that was the only part needed. To achieve that I switched to using JSON from the stdlib instead of MutliJson
This could probably have been fully deleted, since it's only used in test. This allows us to remove unnecessary and expensive data from the spec files.
This about halves the memory usage of the gem
jhawthorn
force-pushed
the
fix_eager_loading
branch
from
664d22b to
4329b8a
Compare
Author
|
Rebased and tests should now be fixed 🤞 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously this attempted to lazy load specs to avoid wasting memory, however this unfortunately had the opposite effect.
In production we want to load as much as possible as early as possible, as after booting the application we fork 16 workers from a parent process. Memory from the parent process can be shared with the children via the operating system's Copy on Write mechanism (not everything gets shared, I've been using 2/3 as a rule of thumb). Even if nothing was shared, it would be desirable so that we don't incur the expense of initialization and extra GC costs while in the middle of serving a request to the user.
We've been looking at heap dumps from production and elastomer client is one of the top contributors to "objects made after boot which persist for the life of the application". As far as I can tell at least two of these specs are loaded. This both wastes memory and slows down GC during application boot.
The first commit in this PR accomplishes eager loading, which uses an extra ~6.5MB of RAM. I think this would be desirable on its own. (better to waste that once than waste half of it 16 times).
The rest of the commits reduce memory usage by removing unnecessary data from the files, using arrays instead of hashes, and adding
frozen_string_literal: true.If we wanted to go further we could load the specs from JSON (which is cheaper than loading Ruby, it's a simpler language) and also de-duplicate between the versions, but I think this is a decent improvement for now.